本篇文章為政治大學 Google 學生開發者社群（Google Developer Student Club, GDSC）與 Women Techmakers (WTM) 團隊合作舉辦之 UIUX 專家講座的學習筆記與心得，這場活動是在 10 月 26 日由臺北醫學大學 GDSC 社長 陳宇心（Eunice）帶來的「UI/UX 概念初探 + Figma 上手：UI 原型製作工作坊」後，針對 UI 與 UX 的進階講座。
講者陣容
- 主持人：Eva (WTM Ambassador)
- 第一部分主講人：黃翎 Lynn（AJA 大予創意 UI 設計師）
- 第二部分主講人：陳文憶 Wendy Chen（國泰世華銀行 UI 設計師）
重點節錄
兩位講者分享的內容都圍繞在過往擔任設計師的實務經驗，第一部分摻雜了設計相關理論、第二部分則提到開發流程與工具等。
第一部分：UI UX Know-how
講者 Lynn 在最開始帶出由丹麥設計中心提出的「設計階梯（design ladder）」 理論，依照產品開發階段、公司發展程度，可分為四個層次：
- 無設計（non-design）：產品剛被做出來時，其發展方向僅來自少數人的想法，基於用戶的觀點並沒有真正參與決策。
- 以設計為美學（design as style）：待產品基本功能確定可行，則會開始針對「產品外觀」進行美學上的優化。
- 以設計為流程（design as process）：設計不再只是錦上添花的表面功夫，而是被整合進開發流程中，從使用者需求為出發點思考。
- 以設計為戰略（design as strategy）：設計也是公司理念與目標的一部分，能夠與其他面向一同推著團隊成長。
丹麥階梯圖（Kretzschmar, 2003）
在簡單講解理論後，講者接著分享自己在 AJA 大予創意的實務經驗。AJA 大予創意是一間口碑非常好、專注於使用經驗的設計顧問公司，成立至今 15 年來，合作並獲得超過 70 個國內外企業的肯定，講者在分享中引用了 AJA 官網的公開案例－「和泰 yoxi-your taxi」。
yoxi 會接觸到的使用者包含企業端（2B）與客戶端（2C），兩者的使用情境不同，設計的方向也要隨之調整。2B 端主要是給司機使用，考量到工作時長、工作環境與對專注度的要求，設計以簡潔易讀為主軸，要能夠在不同環境條件下清楚呈現司機想知道的資訊，例如營收、熱點地圖等；2C 端則是給搭車的客戶使用，在提供流暢的使用者體驗外，也透過大量的企業識別相關主題呈現，加深用戶對於 yoxi 品牌的印象。
第二部分：淺談數位產品思維
講者 Wendy 在一開始便秀出一張「要好、要快、要便宜」的圖，兩兩的交集多半不是消費者會滿意的結果、三者的交集更是完全不存在，而設計師便常常在類似的要求下被賦予各種任務，挑戰不小。
產品的誕生需要多種角色合作，包含前端工程師、後端工程師、測試工程師（quality assurance, QA）、專案經理（project manager, PM）等。開發的流程主要有兩種方式，一種是「瀑布式開發（waterfall）」，表示把所有開發流程跑完之後，產品才上市；另一種是「敏捷式開發（agile）」，透過制定每個短衝（sprint）的目標，快速依照變化需求進行調整。
現今的產品開發流程以敏捷式為主軸，之前在 AppWorks School 受訓時也是用這種方式做專案，跑當下非常熱門的 Scrum 流程，因為這種方法實在太紅，導致我逐漸建立「瀑布式開發比較差」的印象，但講者卻提出了瀑布式開發的實際案例「瑞健醫療 SHL 藥物運送系統」，因為專案規模較小，開發時程大約僅三個月，若採用敏捷式開發，則會耗費過多的時間在會議上，這就是瀑布式開發適合的情境。就像所有的工具與方法，選擇開發流程時，「不是找最好的、而是找最適合的」。
問答時間
活動尾聲有約一個小時的問答時間，兩位講者與在場其他領域專家在回答 slido 上多種不同問題的同時，也分享了許多個人經驗與觀點，這個階段的收穫完全不亞於前面的講座時間。
（照片由政大 GDSC 提供）
以下列出幾個我提的 & 印象比較深刻的問題：
設計多半具有主觀成分，是否有客觀的量化評估方法？
一種是眼動儀的熱點分析，透過追蹤使用者眼球移動取得數據，或者透過 hotjar 等熱點分析工具，追蹤使用者行為；現今比較常做的是 A/B 測試，藉由比較不同版本的數據，得知使用者偏好。
如何決定顏色色號？若兩顏色眼睛看起來一樣時，怎麼挑？
如果是從零到一發想主題與搭配顏色，則以主觀判斷較多，但若已經有主題顏色，挑選其他配色時就要留意彼此的搭配效果；若出現同一色系但色號不同，則可能為誤植所致。
最常跟設計師吵架的團隊角色是什麼？為什麼會發生？如何化解？
其實設計師跟每個角色都會有觀點與意見不同的時候，根本原因是「不清楚其他角色的困難點」，要能夠在意見分歧時找到各種角色都認可的解方，根本方式就是要理解其他人在做什麼、想什麼。
切版應該由設計師負責、還是前端工程師負責？
（設計師觀點）應該由前端工程師負責，但設計師若能夠具備 CSS 或相關延伸函式庫的能力，與前端工程師的溝通會更順暢，若做出來的畫面無法透過樣式碼呈現，也能夠更快理解其難處，以及可能的調整方式。
前端工程師是否也需要有美感？
（設計師觀點）需要！前端工程師的許多工作都跟畫面有關，且會與設計師密切合作，理應也要有美感。值得一提的是，連後端工程師也被認為應具備美感，因為後端也會跟前端合作，例如在設計 API 時，如果已經考慮在畫面上的呈現方式，前端團隊使用時會更方便。
結語
「設計」一直是我只聽過表面、卻未曾探究裡面的領域，雖然國中就讀美術班，求學、乃至就業後的同儕也有不少人在這個領域耕耘，平常聚會倒也不太容易聊到他們的專業，工作上的互動則頂多是提需求、看成果，因此，這場講座可以說是我在 10 月 26 日的短講之後，第一次深入聆聽設計師的經驗分享與洞見。
我曾經感到十分疑惑，畫面好不好看、產品用起來順不順，不是只差在「使用者用起來爽不爽」而已嗎？把這錦上添花的層面拿掉，對產品、乃至於公司有什麼影響呢？Lynn 在分享的尾聲提到 2020 年花旗銀行烏龍事件，因為使用者介面設計問題，居然就導致轉帳時，把原本應給債權人的 780 萬美元匯成近 9 億美元，透過訴訟追討仍敗訴，造成虧損。這給了我非常大的震撼，原來使用者介面與使用者體驗不是只關注「好用」跟「不好用」，如果設計上有瑕疵，是有可能導致使用者犯錯，付出巨大代價的。
截圖自數位時代報導
在工作內容方面，兩位講者雖然都是設計師，但工作時實際花在設計專業的時間非常少，只有約 30%、甚至不到 10%，剩下的時間都是在「溝通」，跟之前聽到的工程師工作狀況十分類似。在開始跟職場接觸後，我發現不管是什麼角色，哪怕是一般被認為較不需要與人互動的科學家、工程師等，其實都非常注重「溝通」與人際關係，跟大學以前講求作業或考試成績及 GPA 十分不同，甚至求職面試時，也是注重溝通過程勝過最終結果，而要能夠跟不同角色順暢溝通，保持開放心胸，理解不同領域的人在做什麼十分重要，這也是我就算未來不以設計師為職涯目標，這場講座還是聽到忘我的緣故。
活動尾聲，政大 GDSC 社長 Kyo 詢問大家「滿分五分，今天的講座給幾分？」，我沒投三分、沒投四分、也沒投五分，因為我想選的是「超過五分」！因為講座時間較久，如果有其他安排其實可以提早離開，但我可是坐好坐滿待到晚上十點、綜合大樓阿伯開始趕人為止，而且還聽得不過癮！所幸，Wendy 推薦了兩個設計主題的播客節目「設計游牧（Design Nomads）」與「No Shortcuts 沒有快捷鍵」，Lynn 也有經營一個播客節目「空想科研（Kuusou Science）」，如果對設計主題的分享依然聽得意猶未盡，就持續收聽這些廣播節目、接收新知吧！
活動尾聲大合照（照片由政大 GDSC 提供）
